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Tools built on top of large language models can produce impressive looking code in 
response to text prompts. Is this enough to enable non-technical people to produce 


real software? 


Generative Al and large language models (LLMs) have attracted serious attention recently 
and one of their many accomplishments is the ability to produce code. Now, these 
technologies are relatively new and they have their fair share of challenges including 
hallucinations and copyright disputes. Assuming that all these other problems can 
somehow be addressed, how does the prospect of using natural language as a kind of 


programming language really stack up? 


On the face of it, natural language seems like the ultimate way to code. After all, most 
people over the age of four already have some level of proficiency. So in theory, nearly 
everybody should immediately be able to program - without the need for lengthy training 
and having to memorise huge quantities of technical detail. That is quite a compelling 


prospect. 


To an extent it seems to deliver. For example, entering a text prompt such as "give me the 
code for the factorial of every factorial in JavaScript" into a tool like Microsoft Copilot 
returns a plausible looking solution - along with some nicely written narrative. You can also 
try different programming languages, ask for test cases and even get it to calculate results 


with ridiculously large return values. 
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However, unless the person using the tool can code, they have no real idea what the 
proposed solution actually does. Yes, they can read the text description - if there is one - 
but there is no guarantee that this is correct or even relevant. The input prompt isn't much 
help either. Natural language can be vague and is often ambiguous - like the factorial 
example above which can be interpreted in a number of ways. Language also tends to be 
laden with assumptions, which are by definition unstated. The only way you can be sure 
that you got the code you wanted - or even the code you asked for - is either to understand 
the code itself or else produce your own comprehensive set of test cases. If you were 


using Zoea you would only need to produce the test cases. 


Nevertheless, non-technical humans have been causing software to be created, largely 
through the medium of natural language for nearly as long as computers have existed. 
These people are the stakeholders in any software development project. Stakeholders are 
often experienced end users that know a lot about their own domain but usually know little 
about software and - without help - they can even struggle to articulate software 


requirements. 


Analysing software requirements is a skill that is different from but just as important as 
coding. It involves eliciting, capturing and structuring requirements, as well as identifying 
and resolving gaps and contradictions. Good analysts also understand the broader 
business and technological contexts - so they can spot problematic requirements which 
just don't work or that might jeopardise security, performance and usability. So while 
stakeholders are the source of most software requirements, the end result of requirements 


analysis is a synthesis of both stakeholder and analyst knowledge and experience. 


People can interact with computers about software in one of two possible ways. You can 
talk about the software in software terms - in which case all parties need to be able to 
code. Alternatively, they can communicate in terms of the software requirements. This 
requires some form of explicit requirements model that all parties can examine, 
understand and modify. Modern Al makes extensive use of models but these are highly 
abstract, mathematical and opaque. Requirements modelling on the other hand has more 
in common with classic approaches to Al. This includes both how knowledge is 


represented and also how it is reasoned with. 
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Natural language plays an important role in describing software but it is not always the 
best approach. Most non-trivial code has multiple execution paths that account for different 
scenarios or the various ways that the software can be used. While it is certainly possible 
to describe all of this using text, the result quickly becomes long, tedious and impossible to 
comprehend - increasing the risk of errors and omissions. This is why people use 
diagrams and tabular notations to describe software - in conjunction with text. If anything, 
the prospect of Al being involved in requirements analysts and code generation only 


increases the need for such multi-channel communication. 


There is also a social dimension to coding that needs to be considered. Most software 
development involves multiple stakeholders, analysts and developers. This requires multi- 
party communication - which is not the same thing as many unilateral conversations. 
Indeed, social collaboration of this sort is a more fundamental problem than a domain 
specific instance like software development. This implies it is a problem that needs to be 


solved first - it is not just something that can be bolted on afterwards. 


Going forward, natural language clearly has a role to play but on its own it is not really 
sufficient to allow non-technical people to develop real (non-trivial) software. The tools for 
their part also have to do more than just be able to code. They will also need to be able to 
carry out requirements analysis and this will require skills like the ability to reason - 
something that LLMs aren't particularly good at and indeed were never designed to do. 


The open question is how these gaps will be filled. 
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